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TO ALL WHOM IT MAY CONCERN: 

Be It known that we, Carl D, Dvorak, a citizen of the United States, 
residing at 9113 Aspen Grove Lane, Madison 53717, in the County of Dane and 
State of Wisconsin; and SUMIT S, RAN A, a citizen of India, residing at 6702 
Schroeder Road, #23, Madison 53711 in the County of Dane and State of 
Wisconsin; have invented a new and useful RULES BASED TICKETING FOR SELF- 
SCHEDULING OF APPOINTMENTS, of which the following is a specification. 



Rules Based Ticketing For Self-Scheduling 
Of Appointments 

Cross-Reference to Related Applications 

5 This application claims priority to United States Provisional Application 

Serial No. 60/263,651, entitled "Rules Based Ticketing For Self-Scheduling Of 
Appointments," filed January 23, 2001 (attorney docket no. 29794/37078) and 
United States Provisional Application Serial No. 60/214,219, entitled "Integrated 
Patient and Enterprise Health Record System," filed June 26, 2000 (attorney docket 
10 no. 29794/36547), the disclosures of which are hereby expressly incorporated 

herein by reference. 

Field of the Invention 

The present invention relates generally to health record management, and 
more particularly, the present invention relates to a rules-based scheduling system to 
15 allow a healthcare facility to control appointments scheduled through the Internet 

with "scheduling tickets" that incorporate a variety of rules. 



Background of the Invention 

Many attempts have previously been made to streamline the process of 
20 scheduling appointments for patients in the healthcare industry. From a healthcare 

organization's point of view, the most efficient method is to let patients schedule 
appointments themselves. However, until the advent of the Internet, this solution 
was not feasible. Now, the Internet has provided patients with direct access to an 
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organization through the web, thereby opening up the possibility of self-scheduling. 
Nevertheless, self-scheduling over the Internet presents unique and interesting 
problems. For example, there are always security issues when dealing with medical 
information on the Internet. Also, if the system is not implemented properly, 
5 patients could abuse the system. Furthermore, Healthcare providers, such as 

doctors, nurses, and surgeons often have concerns that they are losing control of 
their daily schedules if they allow patients to schedule their own appointments. 

The existing scheduling solutions are based on messaging or very restricted 
access. These solutions allow patients to enter some limited information concerning 

10 an appointment. Some examples are: (1) which provider the patient wants to see, 

(2) the day and time the patient wants to be seen, (3) some of the patient's insurance 
information, and (4) a few other types of information relevant to scheduling. 

After requests were submitted in the previous systems, workers at the clinics 
were then required to review each of the requests and contact every patient 

15 individually to inform him or her whether or not the request was granted. While 

this process is somewhat convenient for the patients, it does not automatically 
schedule appointments or immediately enter the data into the organization's system. 
Rather, it relies on human intervention to evaluate the requests and contact the 
patients when the decision to schedule the appointment has been made. 

20 There is a demonstrated need for healthcare organizations to allow the full 

scheduling of appointments over the Internet in an automated process that gives 
patients immediate results and eliminates the need for employees of the facility to 
review each request for an appointment. None of the previous systems satisfied this 
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need. 

Brief Description of the Drawings 

5 FIG. 1 is a flow chart representation of the path that the system would take 

when a patient attempted to schedule an appointment directly from the system. 

FIG. 2 is a flowchart that illustrates the process by which a user logged in to 
his Patient Health Portal (PHP) Web Page can schedule an appointment that has 
been pre-qualified. 

10 FIG. 3 is a flowchart illustrating the components and connections from the 

enterprise healthcare information management system through the Internet and on to 
the patient via a web page portal. 

Detailed Description of the Preferred Embodiments 

15 According to a preferred embodiment of the invention a system that enables 

a patient to use a pre-authorized or a user initiated scheduling process that utilizes 
hierarchically-layered rules. The system further provides dynamic feedback to self- 
schedule appointments with a user's preferred clinics and providers in a confidential 
and secure manner. 

20 The rules based ticketing system for self-scheduling provides healthcare 

clinics and providers the ability to manage and control patient appointment 
utilization. For several reasons, it is very desirable from a healthcare provider's 
perspective to allow patients to schedule their own appomtments. It is also desirable 
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from a patient's perspective to be able to independently schedule their own 
appointments at their convenience through the Internet. A system according to the 
preferred embodiments of the invention satisfies the desires of both parties. 

A rules-based scheduling system according to a preferred embodiment of the 
5 invention allows a facility to control appointments scheduled through the Internet 

with "scheduling tickets" that incorporate a variety of rules and triggers. These 
rules can be defined as many things. Some examples that may be included are: 

(1) The type of patient. The system checks if the patient has any special 
conditions, such as being diabetic or undergoing cancer therapy, that would allow or 

10 disallow a patient to self-schedule. A clinic may not want certain patient types 

scheduling their own appointments because some patients need special 
consideration. 

(2) A patient's Insurance. The system checks to ensure that patients have 
insurance or other methods to cover their medical expenses. 

15 (3) Referral information. The system checks to ensure that patients do not 

have any outstanding referrals for that type of visit so that appointments are not 
duplicated. 

(4) Previous visits of a certain type. The system checks if patients are due 
for or require a follow up appointment. For example, a minor operation may 

20 warrant a return visit to remove the sutures. 

(5) Provider preferences. The system takes into account when providers can 
or want to see certain types of patients. For example, if a provider does not want to 
schedule physicals in the morning, the system could reject any ticket submission 



from patients to have physicals scheduled in the morning for this particular 
provider. 

(6) Patient preferences. The system takes into account when patients want to 
be seen by their providers. 

(7) Past patient history. The system checks if factors exist that may change 
whether or not a patient can self-schedule. For instance, a system could deny a 
patient the right to self-schedule because he has a history of more than 20% no- 
shows or cancellations. 

(8) Copay requirements. The system checks if a copay by the patient is 
required for the appointment. Accordingly, the system requires that a patient must 
pay the copay when he or she schedules the appointment. 

These rules could further be set up as a layered hierarchy. They could be 
specified at various levels which include, but are not limited to: 

(1) System level or facility level. This is the least specific level. The 
settings at this level pertain to an entire healthcare facility. 

(2) Department level. This level is more specific than the system level. The 
settings at this level pertain to all providers who work in a specific department of a 
facility. 

(3) Provider level. This level is very specific. The settings at this level 
pertain to only a specific provider. 

(4) Rule level. The specificity of this level could vary, depending on how a 
facility has set up the system. For example, one facility could set up the rules level 
settings as overriding settings at the provider level, while another facility could set 
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up settings at the provider level as overriding the settings at the rules level. The 
settings at this level pertain to only a specific rule. 

Rules set at more specific levels could override rules set at less-specific 
levels. For example, if an entire clinic's system is configured to allow diabetic 
5 patients to self-schedule using pre-authorized scheduling tickets, but a diabetic 

patient attempts to use a scheduling ticket to schedule an appointment in a 
department that does not allow diabetic patients to self-schedule, the patient would 
not be able to self-schedule in that department because the department level is more 
specific than the system level, so it takes precedence. However, diabetic patients in 
1 0 departments that allow diabetic patients to use self-scheduling or in departments 

with no specific rules for diabetic patients could still schedule an appointment with a 
ticket. 

Different rules could also be set up to override other rules. For example, 
provider preference rules could be set up to override patient preference rules when a 

15 patient is using a scheduling ticket to make an appointment. Also, the past patient 

history rules could be defined to override all other rules, because if a patient abuses 
self-scheduling, a facility would most likely not want that patient to be scheduling 
appointments, regardless of what the other rules dictate. 

Furthermore, these rules can be dynamic in their ability to change over time. 

20 For example, the system could revoke a patient's ability to self-schedule if the 

patient abuses the system. Therefore, if a patient self-scheduled three appointments 
and did not show up for them, the system could automatically change the patient's 
status from 'able to self schedule' to 'unable to self schedule.' 



-7- 

While the invention is further described in terms of several preferred 
embodiments, it will be appreciated that the invention is not limited in scope to the 
embodiments herein described. Many modifications, alterations and additions may 
be made without departing from the fair scope of the invention. 
5 Referring to FIG. 1 of the drawings, a flow chart representation is shown of 

the path that the system would take when a patient attempted to schedule an 
appointment directly from the system. Through the system, a patient with access to 
self-scheduling can, either with a pre-authorized scheduling ticket or through a user 
initiated scheduling process, request an appointment with his or her clinic or 

10 provider. The self schedule request would then have to pass a series of checks, or 

rules, before it could be fulfilled. First, the system would run 104 a rules check to 
see 106 if the patient is authorized to self-schedule appointments. If the patient has 
the appropriate authorization, the system would then check 110 to see if a pre- 
authorized scheduling ticket existed for the patient. If one existed, the system 

1 5 would offer 1 14 the patient time slots that met the ticket requirements. 

If there were no pre-authorized ticket for the patient, he or she would enter 
an appointment search criteria manually 112, Then the system would verify that the 
patient was allowed to see the search results, whether the search results were 
obtained using the pre-authorized ticket or using search criteria initiated by the 

20 patient. The patient would then select 118 an appointment to schedule. The system 

would perform 120 one last check to make sure the patient was allowed to schedule 
the appointment and that the appointment was still available, and then the 
appointment would be made 124. If the specific appointment that the patient was 
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trying to book was unavailable, the patient would be prompted 1 12 to enter 
scheduling information manually, and the process would start over. 

Again, if the scheduling ticket or the responses from the user initiated 
scheduling process pass all of the appropriate security checks, the system then can 
5 present the patient with a list of solutions that match his or her request. After the 

patient selects an appointment 118, the system can perform 120 a final check to 
ensure that the patient is authorized to use the ticket to schedule the appointment and 
that the time slot is still available. If the request passes this security check, then the 
system can notify 124 the patient that he or she has successfully scheduled the 

10 appointment with his or her clinic or provider. If for any reason, a patient is not 

allowed to self-schedule, the system could be configured 108 to immediately give 
the patient the option to request an appointment, as opposed to actually scheduling 
one with a scheduling ticket- 
As explained above, a patient can self-schedule an appointment with his or 

15 her clinic or provider using either a pre-authorized scheduling ticket 114 or through 

a user initiated scheduling process 112. As shown in Figure 2, a pre-authorized 
scheduling ticket is an electronic ticket that is given to the patient via their 
electronic health record managed by their physician. This record is stored on a 
computer server and is referenced by the Internet based scheduling system to limit 

20 the patient's ability to schedule appointments to what is described 204 by the ticket. 

An electronic database of scheduling tickets (also referred to as access 
tickets) would be created. Attributes 204 of records in this database would include 
the healthcare provider who authorized the ticket, the services the ticket entitles the 
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patient to schedule (e.g. one follow up visit within the next two months), and the 
patient identifier for the patient the ticket is for. The ticket also has an attribute that 
describes its current status (unused, appointment made, appointment completed). 
These pre-authorized scheduling tickets would be automatically created 
5 during the physician's documentation of a clinical encounter with the patient. 

Typically a doctor will document when a patient should return, in follow up of a 
problem (e.g. to check on how well a medication is working to control the patient's 
blood pressure) or for a follow up procedure (e.g. suture removal). When initially 
created, the ticket's status is set to "unused." 

10 Referring again to FIG. 2, the flowchart illustrates the process by which a 

user logged in to his Patient Health Portal (PHP) Web Page can schedule an 
appointment that has been pre-qualified. The structure and functionality of a PHP 
Web Page is described in the commonly assigned United States Patent Application 
(attorney docket no. 29794/36547A) entitled "Integrated Patient and Enterprise 

1 5 Health Record System, " the disclosure of which is hereby expressly incorporated 

herein by reference. When the user clicks the Schedule Appointment option, the 
Web Server queries 202 the Scheduling Server to see if there are any pre-qualified 
appointments available for the current user. If there are, the Web Server updates 
208 the PHP Web Page with the available appointment information. The user can 

20 then select 210 an appointment to schedule, and indicates date, time, and locations 

(selections may be limited by information in the Scheduling Ticket database). The 
Web Server then obtains 214 appointment times available within the selected range 
and displays 218 them, whereupon the user can either select a time, change the 
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search, or cancel. When a user completes the appointment scheduling process, the 
Web Server notifies 224 the Scheduling Ticket database that the appointment has 
been scheduled and the ticket for the current user is updated 226 accordingly. The 
Scheduling Ticket database will then track whether the appointment has been 
5 cancelled or completed, and will update the corresponding pre-qualified appointment 

record accordingly. 

As previously mentioned, in addition to direct provider created tickets, 
patients may schedule an appointment through a user initiated scheduling process 
112. An example of when this may be utilized is when a provider places a patient 

10 on a disease management protocol. These protocols might call for a patient to be 

seen with a certain frequency for specified types of visits. These protocols would 
automatically grant authority for the patients that conform to the limitations of the 
protocols. This process could be used independently or in combination with other 
insurance information available for the patient and represents the limitations that 

15 would be imposed on a patient self-scheduling through the web. 

To provide additional control for healthcare providers, the system may be 
designed to apply a more restricted set of rules to patients scheduling appointments 
through the user initiated scheduling process. For example, a healthcare provider 
may reserve only a few time slots per week for patients to schedule appointments 

20 through this process. They may additionally limit those appointments to very short 

durations for limited purposes, such as consultations or the administration of simple 
tests. Another example is that the system could restrict a patient from selecting a 
provider or a department. Instead, the system would pick an appropriate provider 
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or department from a pre-determined list that is driven by the patient as a 
parameter. 

The patient would be provided access to a self scheduling application (e.g. a 
web site or a computer application for personal use, possibly running on a home 
5 computer, personal digital assistant (PDA) or cellular telephone) which would allow 

them to schedule the appointment . 

This self-scheduling computer application would identify and authenticate the 
patient and read the database of electronic tickets to determine what self-scheduling 
limits exist for the patient. The self-scheduling application then allows the patient to 
10 select appointments that are within the limitation of the ticket. 

Once an appointment is made, it is associated with the ticket. The ticket is 
then marked as "appointment made." When the appointment is kept, the ticket is 
marked as "appointment completed" and then subsequently destroyed or retained for 
historical analysis. If the patient or provider cancels the appointment, the ticket's 
1 5 status would revert to the "unused status. " 

The integration of the self-scheduling component into an overall healthcare 
management system is shown in Figure 3. A completely integrated system provides 
patients with secure, real-time access to their Personal Health Record and an 
Enterprise Health Information System (PHR and EHIS, respectively). Access may 
20 be provided by way of the Internet 316 and via a Personal Health Portal (PHP) web 

page 318. From the secure PHP web page 318, patients can view information 
created and maintained by their health care providers and their affiliated staff. The 
patients can also request services and information from their health care providers 



and affiliated staff, directly access EHIS-related services, such as scheduling an 
appointment, paying a bill, enrolling in a class, completing insurance and other 
forms, and viewing information and Internet services that are relevant to their 
particular health status. 
5 In a preferred embodiment of the invention a patient health record data 

server 302, including a machine readable media having a data structure containing 
patient-created data, is coupled by an electronic network with a patient interface. 
The electronic network may be the Internet 316 and the patient interface may be a 
suitable Internet access device including a browser for supporting a personalized 

10 web page 318. A secure interface securely couples, in real-time, the patient health 

record server 302 to an enterprise health record system 304 for providing access by 
the patient to patient-related data retained within the enterprise health record system 
304. Thus, the patient, via the patient interface, may access the patient health 
record server 302 for manipulating the patient-created data and for accessing the 

15 patient-related data from the enterprise health record system 304. 

Referring again to Figure 3 of the drawings, the system includes a Patient 
Health Record (PHR) data server 302, an EHIS data server 306, and a self- 
scheduling server 308. The PHR data server 302 may be any suitable platform 
including processing, memory and data storage capability to perform the functions 

20 herein described. The PHR data server 302 stores data entered oy the patient within 

a data structure configured within the storage portion of the PHR data server 302. 
A secure interface or EHIS queue securely couples the PHR server 302 and the 
EHIS data server 306 for conmiunication of data and ixiformation from the PHR data 
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server 302 to the EHIS data server 306. The EHIS queue provides a real-time 
secure communication link for information moving from the PHR data server 302 to 
the EHIS data server 306. This queue is used to transfer information for secure 
messaging and self-service options. In response to information received from the 
5 PHP web page 318, the PHR data server 302 forwards information to the EHIS 

queue. Information in the EHIS queue is then processed appropriately by the EHIS 
data server 306. 

While the specific configuration of the EHIS data server 306 is not particular 
to the structure and function of the present invention, preferably, the EHIS data 

10 server 306 is a single data repository structured to support both the separation and 

the sharing of data. As such, the EHIS data server 306 may receive information 
from existing outpatient and inpatient data management systems via interfaces or 
from various integrated applications. The EHIS data server 306 may be configured 
to organize information into a consistent whole to provide a longitudinal patient 

15 record. For example, the EHIS data server 306 may be linked to manage all aspects 

of a patient's hospital health status and care and to support effective management of 
patient lists, results inquiry management, complete clinical documentation, 
physician order entry with decision support, nursing workflow and documentation, 
and discharge plarming. 

20 The EHIS data server 306 may further be configured to support the inclusion 

of problem lists, order communications, results reporting, pharmacy management, 
quick documentation, clinical messaging and communication. Additionally, the 
EHIS data server 306 may be configured to manage referral mformation, up-to-date 
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progress notes, lab results, discharge instructions, portions of a patient's record, 
and emergency summary cards. A suitable data management product that may be 
adapted as the EHIS data server 306 is the Epicenter® Entei-prise Data Repository 
and related suite of products available from Epic Systems Corporation of Madison, 
5 Wisconsin. 

The specific configuration of the scheduling server 308 is also not particular 
to the structure and function of the present invention. However, the scheduling 
server may be any suitable platform that includes a processor, memory and data 
storage capability to perform the functions herein described. These functions may 
10 alternatively be performed by the EHIS server 306. Thus, the scheduling server 

308 may be a separate component from the EHIS server 306, or it may be one in the 
same. 

An electronic network couples the PHR data server 302, the EHIS server 
306, and the scheduling server 308 to a patient interface. While Figure 3 depicts 

15 the scheduling server 308 as a separate component, as mentioned above, an 

alternative embodiment may include the scheduling server as part of the EHIS 
server 306, as represented by the phantom line 304 in Figure 3. The electronic 
network may include the Internet 316 or another suitable data network. The system 
servers are electronically linked to the Internet by a web server 312 in a highly 

20 secure dual firewall configuration. In this arrangement, a primary fire wall 314 

protects the web server 312 and a secondary fire wall 3 10 protects the PHR data 
server 302, EHIS server 306, and scheduling server 308. Additionally, the PHR 
data server 302, EHIS server 306, and scheduling server 308 are also electrically 
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interconnected. 

Patients access the system by logging into the web server 312 via the patient 
interface. The patient interface is preferably configured as a web page displayed 
within a web browser running on a suitable platform, and is further preferably 
5 configured as a personalized Personal Health Portal (PHP) web page 318 providing 

the patient with patient-specific information and links to the features and services 
offered by the invention. The web server 312 may be any suitable web server 
platform containing routines for displaying the PHP web page 318 and for managing 
online communication between a user logged in via an associated PHP web page 

10 318, the PHR data server 302, and the EHIS data server 306. 

Rules-based scheduling tickets solve the many probiems that the healthcare 
industry has encountered. First, the scheduling ticket could be sent to the facility 
via a secure web-access application ensuring that the request will remain 
confidential. Furthermore, the self-scheduling functionality is equipped with a 

15 dynamic feedback system, which prevents patients from abasing their self- 

scheduling capabilities. For instance, if a patient schedules multiple appointments 
and does not show up for the appointments, the patient could be banned from 
scheduling any more appointments over the Internet. Finally, because of the 
hierarchical rules that a facility could enact, the facilities, departments, and 

20 providers are able to determine which patients can use scheduling tickets and which 

time slots they can schedule in at different levels, so that they do not lose control of 
their daily schedules. 

The invention has been described in terms of several preferred embodiments. 
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It will be appreciated that the invention may otherwise be embodied without 
departing from the fair scope of the invention defined by the following claims. 



